The Signaling Compression (SigComp) compression protocol (RFC 3320) defines a universal decompression virtual machine (UDVM) and a compression state handler run by a decompressor. SigComp provides a safe environment where the compressing party can ask the decompressor to execute a decompression program and store a decompression state.
FIG. 1 illustrates two variants of a SigComp message format. A format 12 can include a header section 14, a returned feedback section 16, a partial state identifier section 18, and a remaining SigComp message section 20. The format 12 uses an existing bytecode program. A format 22 can include a header section 24, a returned feedback section 26, a code and destination section 27, a UDVM bytecode section 28, and a remaining SigComp message section 30. The format 22 includes the bytecode within the message.
The decompression programs are written with the UDVM bytecode. The UDVM bytecode can either be sent within a SigComp message or it can be stored in the decompressor. Bytecode that is stored in the decompressor can be referenced by its identifier, a 6 to 20 byte long hash of bytecode. A compression algorithm can be readily available in every decompressor, and it can be used by simply specifying a hash code identifying it.
The SigComp message can be either self-contained or it may refer to states within the decompressor. A self-contained message can be statelessly decompressed. The compressor can get feedback from its UDVM decompressor program. The returned feedback can be piggy-backed as a cookie in the SigComp message sent by the peer compressor.
FIG. 2 illustrates an example of a SigComp communication system 33. In the communication system 33, a device A is a device B's peer and the device B is the device A's peer. For instance, if the compressor in device A wants to get feedback, it includes the instructions to get it in a bytecode program which it sends to device B. The device B executes the bytecode, and gets a request from device A's bytecode to send a feedback item to the device B. The device B does not need to understand the meaning of feedback item, it is just a cookie. When the device B sends a message to the device A, it attaches the feedback cookie to its own message.
The decompressor can provide information about its parameters (e.g., supported SigComp version, allowed bytecode execution cycles, available memory size, etc) to the compressor. This parameter information is included in the bytecode. For instance, if device B wants to give its UDVM parameters to the device A, it includes appropriate instructions in the bytecode it will send to device A. The bytecode instructions then generates a well-known returned parameters structure that describes device B's capabilities, and passes it to the device A's UDVM.
The SigComp decompression algorithm enhances compression by using dictionaries. These dictionaries can be static or dynamic. Static dictionaries are either well known or uploaded by the compressor. Dynamic dictionaries are updated by the decompression algorithm. A decompression algorithm can, for instance, store the message headers to the dictionary, so when a next message is sent, the headers can be referenced efficiently.
The messaging session relay protocol (MSRP) is a simple means for exchanging Multipurpose Internet Mail Extensions (MIME) messages between two endpoints. Between the endpoints there can be up to two messaging relays. The relays make it possible to establish a messaging session through middleboxes (firewalls, NATS, etc.).
FIG. 3 illustrates communication between the device A and the device B via relays RA and RB. The messaging session protocol in a communication session is transaction-based (request/response). A session carries two kind of request messages: (1) control messages used to establish and authenticate messaging sessions with relays, and (2) user requests messages that actually carry instant messages between endpoints. The relays are typically interested only in control messages. When a messaging session is uncompressed, the relay can determine the type (control or user) of the incoming request. The first few bytes of the message contains the request type and the size of the message. The user messages can simply be forwarded to the outgoing connection without further inspection.
FIG. 4 illustrates one of the limitations of conventional intermediate elements, or relays, during a messaging session. The messaging stream consists of two kind of messages, control messages that are processed by the relays and end-to-end user messages that are processed only by the endpoints. If the messaging session is compressed, the relays have to decompress using a decompressor (D) and re-compress using a compressor (C) the messaging stream that flows through them. A relay cannot pass compressed messages through as they have to determine the type of each message. In order to efficiently decompress all messages, they have to maintain separate compression contexts with every endpoint. With a large number of messaging sessions flowing through them, this may require disproportionate amount of resources.
FIG. 5 illustrates a SIP (Session Initiation Protocol system where it is possible to compress the message body end-to-end. If hop-by-hop compression is used, the message headers are compressed using hop-by-hop and the compression is applied to the message body twice. It is possible to partially solve the problem by only compressing the low-bandwidth links. Nevertheless, such a solution to the inefficiencies of a SigComp communication system is limited to the scenario where uncompressed messages can be transmitted.
Thus, there is a need to avoid resource-intensive decompression and compression SigComp systems and methods. Further, there is a need to simplify SigComp states of relays. Even further, there is a need to put multiple user messages in one SigComp message and multiplex control and user-plane messages.